This repository was archived by the owner on Jul 8, 2025. It is now read-only.
feat: Non-Breaking SSS Rework#11
Closed
louis1706 wants to merge 17 commits intoExSLMod-Team:devfrom
Someone-193:JustTurnOnTheFemurBreakerLilBro
Closed
feat: Non-Breaking SSS Rework#11louis1706 wants to merge 17 commits intoExSLMod-Team:devfrom Someone-193:JustTurnOnTheFemurBreakerLilBro
louis1706 wants to merge 17 commits intoExSLMod-Team:devfrom
Someone-193:JustTurnOnTheFemurBreakerLilBro
Conversation
Prepare branch
Only bad thing about this is the fact that the constructor for most settings is now ambiguous unless you specified every input. (not breaking tho 💰 💰 💰 💰 )
Removed default values from obsolete constructors, making the Ambiguous constructor reference error impossible. Added a SubGroups property to SettingGroup to handle recursive groups of settings. SubGroups defaults to null but I made sure to check it in them methods that call it. Notably SettingGroup::GetAllSettings(); that recursively gets all the SettingBase contained within it. I added checks for recursive stuff and an error for it. I also added SettingGroup::GetViewableSettingsOrdered(Player) that gets all the settings viewable by a specified player as well as ordered by priority etc...
some last minute tweaks including fixing the List<> renting I was doing
Legit realized my recursive check didn't work last night right before I went to bed 😭 This ought to fix it though
…Settings, Add an IReadOnlyCollection of Groups if a plugin-maker manually removes a ServerSpecificSettingsBase from ServerSpecificSettingsSync.DefinedSettings, it's on them to handle who gets what settings, otherwise making this check simply reduces points of failure
Forgor to check predicate :(
yknow, I really though that checking DefinedSettings for the setting bases before sending them was a good idea, but SOMEHOW SettingBase::Base doesn't return the value stored in ServerSpecificSettingSync.DefinedSettings!?!?!? 😭 Anyways, removed that, added a specified group for the obsolete methods to register into, then made all SettingBase non-group register/unregister method reference that group. Only way this breaks is if some goofy goobers plugin unregisters all settings, clients would see stuff created via group method, but that's why we obsolete stuff, it doesn't affect pre-change behavior so as long as devs have a few brain cells (crazy request ik) we should be good
as far as I can tell this shouldn't mess with the recursive check but make it more accurate. But now you can have multiple of the same group in SubGroups if you'd like (without them being recursive ofc)
github-actions
bot
added
API
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Obsoleted SettingBase.SyncOnJoin, SettingBase::Header, and relevant constructors. Added constructors without Header input. Added SettingGroup class that contains an IEnumerable, int Priority, Predicate Viewers. Priority determines where the setting appears in the clients list of settings (high priority means setting is at top of list) Viewers determines who can see the setting. Replaced all methods that send generalized SSS data (SendToPlayer(Player), SendToAll(), etc...) with methods that reference a new internal static readonly List called Groups. They use this to get the priority of each group, then order them, then convert to an array of ServerSpecificSettingBase to be sent to client. I made sure to keep the functionality of all this stuff (including SyncOnJoin) so in theory this shouldn't break any existing plugins. I thoroughly tested it on my stuff, the only thing that messes with what I made is ServerSpecificSettingSync.SendToAll(); but still, these changes give a LOT of power to the developers. We can order groups of settings, controls who sees them, etc... All without breaking existing plugins. Of course there is one thing that went slightly wrong. The new constructors for each setting type are now ambiguous unless you specify the EXACT form of the non-obsolete constructor, this can be frustrating for devs, but that's about it. Once we get 15.0 though we can just throw out the obsolete stuff which would make the whole SSS process smooth like how it currently is.
What is the current behavior? (You can also link to an open issue here)
📉 📉 📉 📉 📉 📉 📉 📉 😭 😭 😭 😭 👎 👎 👎 👎
This is a non-breaking PR that implements the same features attempted in ExMod-Team#472 albeit in a different manner.
What is the new behavior? (if this is a feature change)
💹 📈 🤑 🔥 🔥 👍 📈 📈 📈 📈 🤑🤑🤑
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No, I tried very hard to avoid this.
Other information:
I believe this isn't breaking and works as intended etc... but it would be best if you all looked over this carefully.
Types of changes
Submission checklist
Patches (if there are any changes related to Harmony patches)
Other